為什麼菜(程式碼)煮好端上桌不等於萬事大吉？如果送到客人面前的過程（整合、安裝)沒有做好防護，或者端上桌後(部署）沒有人確認是否新鮮，客人吃下去還是會吃壞肚子。
餐飲: 建立標準化的出菜流程、確保外送員不能隨意打開餐盒、使用密封包裝，避免在運送途中被「加料」。
軟體: 透過自動化部署流程，減少手動設定錯誤、遺漏組態檔或資料庫腳本未執行等風險。
餐飲: 在廚房試吃還不夠？因為真正的客人有各種奇葩的吃法，且餐廳現場的環境溫度與濕度也跟廚房不同。我們必須在菜上桌後持續抽驗。
軟體: 測試環境通常使用模擬資料，且多數為理想狀態，往往會遺漏正式環境才有的「極端情況（Corner-case issues）」或因部署動作本身所引發的破口。
| 名稱 | 主要功能 | 風險控制／回復能力 | 適用情境 |
|---|---|---|---|
| 藍綠部署 (Blue/Green Deployment) | 同時維持舊版與新版環境，透過流量切換讓新版接手服務。 | 快速切換與回復。發生問題時可將流量切回舊版；若基礎架構與切換機制設計完善，可達到 Zero downtime。 | 需要快速版本切換、降低部署中斷風險的系統。 |
| 金絲雀發佈 (Canary Release) | 先將少量流量導向新版，再依監控結果逐步擴大發布範圍。 | 限制爆炸半徑 (Limits the blast radius)。問題初期只影響部分使用者或流量，可在擴大前停止發布。 | 高風險版本、需要實際 Production 流量驗證的系統。 |
| 滾動式部署 (Rolling Deployment) | 逐批替換既有 Instance，讓新版逐步取代舊版。 | 部署期間維持部分舊版 Instance 提供服務；發生問題時可停止部署並進行回復，但通常比 Blue/Green 複雜。 | 大量 Instance、Container / Kubernetes 等需要逐步更新的環境。 |
| 功能開關 (Feature Toggles / Flags) | 將功能的啟用與程式版本部署分離，可依條件控制功能是否啟用。 | 快速停用功能。發現新功能異常時，可直接關閉 Flag，不必重新部署；但不代表完整版本 rollback。 | 新功能上線、A/B Testing、逐步啟用、緊急停用。 |
| A/B Testing | 將不同版本或功能呈現給不同使用者群組，比較實際使用結果。 | 限制不同版本的使用範圍，並透過實際數據評估功能影響。 | UI/UX、產品功能、商業流程驗證。 |
| Shadow Deployment | 將 Production 流量複製給新版系統，但新版結果不直接回應使用者。 | 低風險驗證新版，可觀察新版在真實流量下的效能與錯誤，不直接影響正式服務。 | 高風險系統、效能驗證、ML/AI Model、新架構驗證。 |
| 重建式部署 (Recreate Deployment) | 停止舊版本後，再建立並啟動新版。 | 部署流程簡單，但通常會產生 Downtime；Rollback 也需要重新部署舊版本。 | 可接受短暫停機、非關鍵系統或簡單部署環境。 |
每次部署的標準配備。如果沒有一條經過驗證的退路，你連部署按鈕都不准碰。
長官(系統擁有者) 點頭放行的簽字。沒有 ATO 就硬把軟體推上線，在商用環境是大忌。
Secure Build & Deployment
https://prodsec.owasp.org/pscf/capability-areas/secure-build-and-deployment
iThome鐵人賽
看影片追技術